Interoperability
Interoperability is the ability of two systems to exchange information and use it. The second half is what makes it hard. Moving bytes is a solved problem; ensuring the receiving system means the same thing by them is not.
Integration is not interoperability
These words are used interchangeably and should not be.
| Term | Means | Scales? |
|---|---|---|
| Integration | Making two specific systems work together, by whatever means | No — cost grows with every pair |
| Interoperability | Systems working together because they conform to shared, published specifications | Yes — cost grows with each system, once |
| Information exchange | The act of moving data between organisations | Depends on the above |
| Health information exchange | The organisation, infrastructure and governance that make exchange routine across an ecosystem | It is the mechanism that makes it scale |
A bespoke nightly CSV between an EMR and the HMIS is an integration. Both systems conforming to a published FHIR implementation guide is interoperability. The first is faster to deliver and is why most ecosystems have forty of them.
The practical test: if a third system arrives, does it reuse the work? If not, you built an integration.
The four levels
Each level depends on the ones below it. Skipping a level does not remove the requirement; it defers it to the point where data is being used, which is the most expensive place to discover it.
┌──────────────────────────────────────────────────┐
4 │ Organisational │
│ Legal basis, governance, agreements, funding, │
│ operating model, trust │
├──────────────────────────────────────────────────┤
3 │ Semantic │
│ Shared meaning — terminology, value sets, maps, │
│ information models, identity resolution │
├──────────────────────────────────────────────────┤
2 │ Syntactic │
│ Shared structure — FHIR profiles, HL7 v2 │
│ message structure, CDA templates, schemas │
├──────────────────────────────────────────────────┤
1 │ Technical / foundational │
│ Connectivity, transport, authentication, │
│ encoding — HTTPS, TCP, JSON, XML │
└──────────────────────────────────────────────────┘
1. Technical
Two systems can establish a connection and move bytes reliably and securely.
Concerns: transport (HTTPS, MLLP for HL7 v2, SFTP for batch), authentication of the caller, encryption in transit, retry and idempotency, rate limiting, availability.
Mechanisms: REST APIs, GraphQL, gRPC, webhooks, message queues, event streams. See integration engines.
Usually the easy level — and the one that gets all the attention, because it is the one engineers can finish.
2. Syntactic
The receiver can parse the message and locate the fields.
Concerns: format (JSON, XML, NDJSON, CSV, HL7 v2 pipe-delimited), schema conformance, versioning, required versus optional elements, character encoding and internationalisation.
Mechanisms: FHIR profiles, HL7 v2 message structures, CDA templates, JSON Schema, validators.
Where conformance testing lives. "It's FHIR" is a technical-level claim; "it validates against the national IG" is a syntactic-level one.
3. Semantic
The receiver understands what the data means, well enough to act on it or count it.
Concerns:
- Terminology — is the diagnosis coded with SNOMED CT, ICD, or a local list? See terminology services.
- Value sets and binding strength — which codes are permitted where
- Units — UCUM, and the difference between mg/dL and mmol/L
- Identity — is this the same patient, the same facility, the same clinician? See registries
- Information model — does "encounter" mean the same thing on both sides?
- Context — negation, uncertainty, family history, planned versus performed. A code for "myocardial infarction" attached to a family history section means something entirely different from the same code on a problem list.
This is the level that determines whether the exchange was worth building. Data that arrives, parses and cannot be pooled has cost money and delivered nothing.
4. Organisational
The exchange is permitted, funded, operated and trusted.
Concerns: legal basis for sharing, data sharing agreements, consent model, governance bodies, conformance certification, incident response, service levels, who pays for the shared components, and what happens when a participant fails to meet its obligations.
Mechanisms: trust frameworks, participation agreements, an architecture review board, national policy. See governance.
This is the level that stops most national programmes, and it cannot be solved by procurement. A technically perfect exchange with no legal basis for sharing does not run.
A diagnostic
When an exchange is not delivering value, work down the levels:
| Symptom | Level | Likely cause |
|---|---|---|
| Messages time out or fail intermittently | 1 | Network, auth, retry design, capacity |
| Messages rejected as malformed | 2 | Profile mismatch, version drift, missing required elements |
| Messages arrive but reports don't change | 3 | Terminology not mapped, identity unresolved, model mismatch |
| Everything works technically but nobody uses it | 4 | No legal basis, no incentive, no operating model, no trust |
| The pilot worked and the rollout stalled | 4 | The pilot had a champion; the ecosystem has governance gaps |
The instinct is to debug at level 1 because that is where the logs are. The problem is usually at level 3 or 4.
Cost of the levels
Rough proportions from national programmes, and the reason budgets are consistently wrong:
Effort actually required Effort typically budgeted
──────────────────────── ─────────────────────────
Technical 15% Technical 60%
Syntactic 20% Syntactic 25%
Semantic 35% Semantic 10%
Organisational 30% Organisational 5%
Terminology mapping and governance are the work. Everything else is comparatively tractable.
In this section
- Health information exchange — the architectures for exchanging across organisations
- Integration engines — the middleware that does routing, transformation and mapping
- APIs — observability and management of API traffic
- OpenHIE — the reference architecture that assembles these into an ecosystem
- Architecture patterns — reusable exchange patterns
References
- OpenHIE architecture — https://ohie.org/
- HL7 FHIR — https://hl7.org/fhir/
- IHE profiles — https://www.ihe.net/
- WHO Digital Health Platform Handbook — https://www.who.int/publications/i/item/9789240013728